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COCO-3 BOOT LIST ORDER BUG 
(BLOB) 

Facts, fixes and theories 

by 
Kevin Darling & friends 



THE BLOB. Some owners have it, some 
have never seen it. Ordering of modules in 
a bootlist for os9gen seems to affect it. 
Adding new devices may cause it to show 
up. What causes it? It's past time to lay out 
both what has been conjectured and what is 
truly known so far. 

At first, the OS-9 kernel itself was blamed. 
VeVe been pretty sure nowfor a long time 
iiat it is NOT at fault. All the modules are 
position-independent, and have been gone 
over very closely by several of us , looking for 
anything that could cause a problem. We 
have found no software cause at all (with 
the exception of the disk driver - see below). 
Instead, hardware and timing discrepan- 
cies in the CoCo-3 and peripherals have 
been found almost always to be at fault. In 
fact, it's often possible to pinpoint the exact 
cause of a particular problem, with enough 
information. 

Enougli preliminaries. Here are most of 
the confirmed and imconfirmed symptoms 
and possible reasons, including things that 
act like BLOBs... 

FLOPPY FORMATTING HALTS IN 
FIRST FEW TRACKS; READMrRITES 
ARE OFF BY A BYTE: 
"en Schunk, myself, and others long ago 
ound that the halt method used by 
CC3Disk (and some RSDOS drivers in 
programs) has a problem with some disk 
controllers (apparently mostly pre-19S5 



1773's). The usual method is to wait for the 
FDC (floppy disk controller) to indicate it is 
ready to exchange a byte of data, and then 
have the CoCo go into the halt mode. What 
will happen is that the first byte transfer 
gets lost, and this is returned as a "Read 
Error" by the driver. 

For reasons as yet unknown, this **data 
lost" sequence sometimes "seems" to be 
driver position dependent. I would guess 
that most boot failures are caused by this 
one^ especially with older controllers (altho 
I've seen it happen on newer ones, too). 
The drivers can be fixed, and we should be 
able to post patches later. 

READSAVRITES GO TO WRONG LSN: 

Actually, they go to the wrong TP^CK, 
which is also always the wrong LSN. 

Usually caused by using disk drives that are 

set to turn on their motors only with drive 

select, instead of the required method of all 

motors on with the motor-on signal. All 

drivers assume that if one motor is on, ALL 

are on. 

Because of this assumption, and especially 

because the drive READY line isn't 

usually available on the CoCo setup, the 

FDC will send stepping commands 

to a drive that is still spinning up again 

when selected (it takes about 1/2 

second to be actually "ready"),... and those 

stepping pulses are totally 

ignored by drives not spun up. So while the 

FDC _thinks_ it's stepped the 

head to a new track, in fact either some or all 

of the step pulses have 

been lost. 

Worse, the 1773 FDC seems to ignore the 
imbedded track information on the 



disk itself (contrary to docs) and so as long 
as the sector nunxber matches up, the data 
is read/written. . . to whatever track the head 
happens to be over! 

So make sure your drive motors all come on 
at the same time. 



SPEED AND BAD CHIPS 
Testing and experiences by several people 
has shown that the American semiconduc- 
tor industry has gotten pretty bad over the 
last few years as far as quality goes. Or per- 
haps retailers are selling more reject chips 
that they buy on the grey market. In any 
case, some failures of chips used in add-on 
devices have been found to be brand de- 
pendent. 

For example, some of the LS245 data buff- 
ers inside CoCo-3*s seem to fail to pass true 
data at times. Replacing this chip with a 
Japanese brand will usually cure this par- 
ticular problem. Motorola chips seem to be 
the worst bet. Symptom is that an instruc- 
tion loop reading from the MPI sometimes 
sees bits set that it shouldn't. Solution is to 
replace the chip or slow down the loop* 
Speedwise, many people use hardware 
designed and built for IMhz operation 
from the CoCol/2 days. A conunon prob- 
lem is with RS232 paks... they may need 
the 6551 replaced with a higher speed ver- 
sion. 

INTERRUPTS 

Boot problems also sometimes appear 
when a device's interrupt line isn'tcorrectly 
reset. I've had several 6551 ACIAs (used in 
PS232 paks, etc) thatdecided not to clear 
their interrupt line just by resetting the 
CoCo. This leaves an interrupt hanging 
and can mess up a machine trj^ing to boot 

It's also been found that some RS232 paks 
were built with the E clock tied to the IRQ 
line... this can abort a boot also. 



Stuck interrupts are covered in J;he various 
"IRQ HACK" files available on most net 
works, as are files on the RS232 pak. 

MULTIPAK UPGRADE 
A non-upgraded MPI definitely causes 
problems. At the least, it can cause wrong 
information to be read from the crucial 
GIME interrupt status port. 
The most common rumor we see on BBS's 
is that the MPI upgrade "isn't needed", 
because **my machine runs fine without 
it". DO NOT LISTEN TO THESE 
PEOPLE. PLEASE EXPLAIN TO 
THEM THAT THEY ARE STUPID. 
While we can't swear that you WILL hurt 
your GIME if you don't upgrade, we can 
certainly say that it does make electronic 
sense to DO the upgrade (plus Tandy sold 
the upgrades at first cheaper than their 
cost, which alone would make one think 
there's a good reason for having it, eh?). 
The electronic reason for the upgrade i: 
this: a READ from $FF80-9F will txim on 
BOTH the GIME data bus AND the MPI 
data bus. (In addition, really old MPIs ghost 
their slot select at $FF7Fand $FF9F, which 
causes problems.) It's never a good idea to 
have tvt'o devices trying to put data on a bus 
at the same time... one of them could get 
hurt (usually the GIME, in reported expe- 
riences). 

Especially under OS-9, where the interrupt 
register at $FF92 is re-ad at least 60 times a 
second, it makes sense to not have that data 
be corrupted by bogus MPI data coming on 
at the same time. So UPGRADE YOUR 
MULTIPAK NOW! 

E-CLOCK SYNCHRONIZATION: 
All accesses to peripherals need to use the 
6809 E clock to validate the transfer of data 
(especially at 2Mh2^). A few early versions^ 
of third-party devices accidentally were 
made with registers that didn't do this. All 
have been fixed for a year now, as far as I 
know. 



Also, sometimes a module (especially 
os9pl) will get hit by an errant program, 
and then you os9gen a new disk... which 
gets perpetuated with the bad os9pl from 
then on through newos9gens. We also find 
that people often reverify a bad module 
quite by accident using disk editors on their 
bootfile, thus hiding future trouble. Keep a 
log of all changes you make, and CRCs! 

MISC THEORIES 

Most other problems fall into the mystery 
section (meaning we don't have a firm 
handle on the caizse yet). I have two pet 
ideas that may or may not make sense, but 
which are bolstered in part by experiences 
by myself and others. 

One is that since interrupts cause the inter- 
nal BASIC ROM to turn on (to get the 
interrupt vectors), the ROM stays on a bit 
too long and corrupts the data bxis at times. 
Probably a dumb theory <grin>. 
The other is that the dead cycles within 
many instructions have an effect. During 
the dead cycle the address bus contains 
$FFFF (which turns on the ROM!) and 
again, perhaps this data sticks around, or 
the address lines change too fast enough 
once in a while from true address to FFFF. 
This ties in with partial evidence that some 
6809s at 2Mhz will start changing their 
address lines immediately after the end of 
an E cycle, perhaps even before E-gated 
devices finish up . We do know that oddball 
reads/writes occur at times to strange ad- 
dresses, and this might explain them. 
A third theory gaining some acceptance 
(but we just don't know how the GIME 
works internally) is that the GIME, like the 
S ANI chip , powers up using either the up or 
down side of the main oscillator clock 
(remember hitting reset on SAM machines 
to get the right red/blue fake color phase? 
likis that). Perhaps one side is better than 
the other. Certainly powering down some- 
times cures a boot or other problem . So who 
knows? 



We also know that changing cpu brands, 
and sometimes switching GIMEs, will of- 
ten cure timing problems and tJiesparklies. 
Not always, though. 

CONCLUSIONS 

We're still gathering data, and occasionally 
do run across something unexplained. For 
the most part though , BLOBs have become 
fairly rare. This may be because people 
have more L-II experience, or newer hard- 
ware, or a combination. 
OS-9 itself is not at fault , and note that even 
RSDOS applications can and do suffer 
from the same symptoms. The basic answer 
is that we moved up to a faster machine, 
while still using older peripheral eqtiip- 
ment. 

Tlie order of the bootlist CAN affect the 
symptoms (as we Ve seen), but this is simply 
software showing up hardware bugs, and is 
NOT the fault of OS-9 itself. 
So the final word is this: our best evidence 
is that there really _isn't_ a boot list order 
bug. Look to your hardware instead. 

-kevin- 

P.S. The above information has been 
gleaned over the past two years from per- 
sonal experience, many phone calls and 
network messages, and the work of Bruce 
Isted, Tony DiStefano, Chris Burke, Roger 
Krupski, DP Johnson, Dave Wiens, Ken 
Schunk, and many others. 

FS: Ifyou have anything to add, please send 
information to me at: 
76703,4227 - CompuServe 
OS9UGPRES -delphi 
uunet!76703, 4227@compuserve.com 




and More. 



Downloadacopyof DIRM. This utility will 
display a directory of the memory modules 
and which memory block each' module 
resides. 



NOTE: The following information is con- 
tained on the inside back cover of the 
DISTO Super Controller II manual. The 
author is Kevin Darling and is offered here 
in a plagiarized form. 

—Rodger Alexander— 



OS-9 LEVEL II FORMAT/BOOT 
PROBLEMS 

When a new bootdisk is made, a boot file is 
used. This is a text file that contains the 
names of all the drivers and descriptors that 
make up your specific bootdisk. The order 
in which these drivers and descriptors 
appear in this list CAN catise problems. 

The symptom is, bootdisks that have 
trouble booting up or formatting disks. 
The formatting problems are more com- 
mon but the cause is not always identified 
as a bad boot disk. 

Changing the order in which the drivers 
and descriptors appear will cure the boot/ 
format problem . It seems that the RBF and 
CC3Disk drivers MUSTre^de in the same 
8K block. If you have modified your boot, 
installed or patched drivers you may have 
caused CC3Disk to drop down to the nexi; 
memory block. Usually nxoving the INIT 
module from it's present position to the 
bottom of the list, works. Remember 
though, the OS9p2 driver niust always be 
the first on the list. You can change the 
order by using EDIT or retyping the whole 
file using BUILD then Tise-OS9GEN*td 
makeanew bootdisk. Another method is to 
actually delete and re-install modules los- 
ing EZGEN. 



Bellingham 0S9 

Fouth Comer 68xxx Mug 

Sehome 0S9 



"What should we call ourselves? Or does it mailer? 
Iffhat does mailer is -whal is our purpose. "Whal is il 
Ihal >»e can provide as a group Ihal -we canrol achieve 
on an individual basis? 

Of course Ihe grealesl advanlage in combining forces 
and meeting as a group is the sharing of our common 
interest in 0S9. Sharing our knowledge, experience, 
and resources to help one another. 0S9 is a powerful 
system that is growing world wide and with the advent 
of the 05-9000 for the 80486/66030-40. we have a lot 
to look forward to. 

PH^EFITS: 

Qub Public Domain Library 

Access to the Gimix multi- tasking 0S9 system 

Group purchases at discounted prices 

Monthly Users Meeting at Sehome High School 

N^3 Letter 

Barbequed RBBS 0S9 Conference. Bulletins and 350 
Downloads 

Demonstrations and Guest Speakers 

Stale-wide 039 User Groups 



CoCo/OS-9 
Software - Hardware 

CoCo Hardware/Software 



PERSONAL COLOR RADAR (Vidlex package for down 

loading radar weather fax) 

MATH TUTOR (Rom Pak) .. 

^.DDIO SPECTRUM ANALYZER (Rom Pak) 

fflCRO wms DS-es digitizer 

8S9TRSCOR^ 

fifW TKSFDIT 

PraaSION TIME MODULE (Real Time Oock Rom Pak) 



ZOKO RAN Rom Pack 

GHANA BWANA (039 Disk Game) 

SUPER SCREEN MACHINE (Disk) 

eOLORCOM/E (Disk) 

S.ANDS OF EGYPT (Disk) 

ONE ON ONE (Basketball Game-Disk) 

BIOSPHERE Game (Disk) 

FLJPSIDE Game (Tape) 

DALLAS QUEST (Disk) 

POOY.AN (tape) 

FUL-O-PAJi (0S9 level-1 screen utilities) 

RS-232Pak 

TELEWRlTER-64 lordprocessor (CoCo 1-2) 

DATAPEN yght Pen (tape) 

MAGI-GRAPH (Disk) 

gflPER PITFALL (Rom Pak) 

MICRO ILLUSTRATOR (039 Disk) 

PlTFALL-11 (0S9 Disk) 

JfEGA-BUG (Rom Pak) 

MUSIC (Rom Pak) 

PEANUT BUTTER PANIC Game (tape) 

CASTLE OF THAROGGAO (Rom Pak) 

PEGASUS (0S9 Disk) 

DESKMATE (0S9 level-1) 

HIGH RESOLUTION JOY SHCK 

RADIO BALL Game (tape) 

DIAGNOSTICS (Rom Pak) 

DUNGEONS OF DAGGORATH (Rom Pak) 

GOMOKU/RENJU (Rom Pak) 

CANYON CUMBER (Rom Pak) 

bask: 09 (Level-; Disk) 

TETKS (iftHB f^i 

Osy Levei-I 

FLIGHT SlMULATOR-1 

PERSONEL FINANCE II (Rom Pak) 

X-PAD 



Januan Meeting 
Sehome H.S. 

Jan, 11 7;30p.m. 
(room 109) 

Agenda: 



Wes Payne has been working on an E-mail type 
of security message base for 0S9 using Basic09. 
Wes will demonstrate and explain the process 
involved. 

Wes has also set up special "USER GROUP" 
access directories on the Gimix. 

Documentation and manuals will be available 
to help us answer the remaining questions 
regarding RMS and the INTROL C Compiler. 

A demonstration of some recent utilities that 
have become a must in solving the Boot Order 
Problem referred to by Kevin Darling at the 
beginning of this Newsletter. 

Group Goals need to be addressed at this 
meeting- 

And hopefully even more CoCo / 0S9 Stuff for 
sale should be available for viewing and pur- 
chase. 
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